On Apr 15, 2007, at 2:43 AM, Ludovic Dubost wrote:
> Author: ludovic
> Date: 2007-04-15 02:43:21 +0200 (Sun, 15 Apr 2007)
> New Revision: 2809
>
> Modified:
> xwiki/trunk/core/src/main/java/com/xpn/xwiki/doc/XWikiDocument.java
> xwiki/trunk/core/src/main/java/com/xpn/xwiki/plugin/lucene/
> IndexUpdater.java
> Log:
> XWIKI-966 Fix lucene indexing not correctly deleting and reindexing
> in some cases
> XWIKI-21 Fix rename regression using copydocument which does not
> clean up the attachment list before copying the source attachment list
[snip]
You can't do that as XWIKI-21 is already closed and released as part
of XWiki 1.0 Beta 6.... So this fix won't show up in the release
notes of RC1...
I've created XWIKI-1085 for this but I need your help to describe the
problem from a user point view. I need the answer to: "what happens
when a user renames a document with attachments?".
Thanks
-Vincent
Hi,
Sometimes it's hard to make the distinction (in a conversation) between
XWiki classes/objects/properties and the java terms. Thus, we should call
them XClass, XObject and XProperty. Of course, class/object/property are
still valid, when everybody knows what we're talking about.
Sergiu
--
http://purl.org/net/sergiu
Hi,
I'd like to propose a new subproject on JIRA, called XWiki Flavors.
What is a Flavor? A flavor is a custom XWiki-based site, with one specific
goal in mind. The XPN team creates such flavors when working for client
project. As it is said on http://jira.xwiki.org/jira/browse/XWIKI-356 , by
default XWiki comes with a collection of pages, panels, classes, a
pre-selected skin, etc, which gives it a "flavor". Right now, it looks like
a nice site where you can put some pages (content), articles, documentation,
etc. It is a weak flavor, since it's a mixture of different ingredients put
all together.
An example of a "strong" flavor is a blog-wiki. When you install XWiki and
choose the blog-flavor, you will get the full functionality of any blog app
(for example blogger or wordpress) without having to customize anything,
without having to import one or several xar-s, editing the main page or
anything. Of course, after the user gets used to the blog (and XWiki) he can
customize the skin (using a friendly skin browser and a skin wizard), the
displayed panels (using the panel wizard), and many other things (actually
anything a user can change in XWiki, which is everything).
Other strong flavors could be content management, OpenSource project website
(about, developer guide, user guide, download, ...), or just the
documentation for such a project (many projects use wikis now), Social
Networking site (link and photo sharing, tagging, reviews), project
management, and so many more.
Why are flavors necessary? Because XWiki is too powerful. Put it in the
hands of some who-knows-what "haskel model checker" developer who only knows
about axioms, theorems, proving, model checking and functional programming,
and he will run away very fast to a simple wiki engine, or worse, a CMS. But
hide all the power behind a simple interface, with only what he needs in
order to publish some info about his project, and we have a happy XWiki
user.
Why do we need a new subproject? Because:
- putting all the flavor-specific issues in the "Default database" component
is not efficient
- neither is putting them in a new "Flavors" component
- we don't know how many flavors we will create, so making an XWiki
component for each flavor will bloat the component list
- flavors don't follow the XWiki platform release plan; they get shipped
when they are ready
What is the relation between flavors, default database, and
xwiki-applications?
The default database should be almost empty. It should contain mainly the
setup wizard, which can be used to install a flavor.
A flavor contains some applications bundled together. It is not enough to
put only the individual applications in JIRA, because a flavor is more than
that: a custom skin, configuration for the applications, rights setup, other
documents outside of applications, java plugins, XWiki configuration, and
even more.
What should the subproject contain? First, a "global" component, regarding
flavor development, deployment, integration, installation. Then a component
for each flavor we are currently supporting (or starting to work on).
WDYT?
Sergiu
--
http://purl.org/net/sergiu
Hi,
I think it's high time we get a powered by XWiki logo! :)
Laurent Lunati has created 5 variations attached.
Does anyone have any feedback in term of size, color, look, etc?
The idea is that once we get an agreement on the logo we publish it
on xwiki.org and we ask that people using XWiki display this badge on
their web site if they want to be good open source citizens :) (and
thus we'll also use it on xwiki.org itself).
My preference goes to the 80X15.png logo. What about you?
Thanks
-Vincent
Does anybody have any hint on where I might get some Google Docs API
Developer documentation? (tried google already, nothing relevant came up for
several well thought search strings).
Thanks in advance,
Radu Danciu
Hi XWiki committers,
We need to better handle patch contributions. It's really important
that when someone submits a patch we review it quickly and apply it
or ask for modifications. Providing a fast answer means that we'll
get more contributions and XWiki will soar even higher...
Right now we're doing a poor job at handling patches. The first step
in improving is in detecting issues with patches.
I have thus started tagging issues with patches with "patch" in the
keyword field. I propose that we all do this whenever we see an issue
with a patch attached.
I have also modified the default JIRA dashboard on http://
jira.xwiki.org/ so that the list of issues with patches attached are
listed in the right column.
If you agree I propose we make it our priority to review and fix
issues with patches attached.
WDYT?
Thanks
-Vincent
Hi,
I'd like to propose the following general principles for the V2
Architecture (http://www.xwiki.org/xwiki/bin/view/Idea/ArchitectureV2):
1) Components can contribute user interface elements.
2) They contribute them through a Java interface.
3) There's one Java interface for each UI contribution (located in a
ui package).
<example - I'm not asking to vote on this, it's just an example to
better visualize what "one Java Interface for each UI contribution"
means>
For example, we have one interface for contributing Admin Pages (the
tabs we have in the administration page when using the albatross
skin). For example:
public interface org.xwiki.core.ui.AdministrationPage
{
Page getPage(Context context);
}
where: Page will return the page's content (the implementation could
have a "String getContent()" method, and some other fields, like a
page id, etc). The context will contain useful information for
returning the page. One interesting information is the skin name if
some component want to return a content that is optimized for a given
skin
The page content could be stored as *.vm file in the component JAR.
The returned content is content that has NOT been processed by any
renderer. We do not want to make these component renderer-aware as
rendering should be done in a centralized manner elsewhere.
The content returned by getPage must not be styled at all. It should
try to return only Wiki Markup. When this is not possible it should
follow general convention that we'll need to publish as an API for
HTML class ids for example.
</example>
4) There are Java UI Interfaces for skins. These are interfaces used
by skins.
<example>
Continuing the example above we could have the following:
public interface org.xwiki.core.ui.skin.AdministrationServices
{
List getPages(...);
}
And the component implementing this interface would query the
component manager to get all components implementing the
org.xwiki.core.ui.AdministrationPage interface, which would be
returned as an output of getPages(). Then a skin implementation (*.vm
files for example, or JSP pages, or...) would call getPages() to lay
out all the administration pages, whether as a tabbed interface or on
different physical pages, etc.
</example>
<example>
Another example to illustrate this is the Import/Export feature. This
could be packaged as a single component which would implement several
interfaces, among which this AdministrationPage interface and provide
the content for the import and export pages.
</example>
WDYT?
After we discuss this and once we agree on it, I'll publish the
results on http://www.xwiki.org/xwiki/bin/view/Idea/ArchitectureV2
Thanks
-Vincent
Hi,
I like to create Czech localization of Xwiki.
I found that some localization files are situated in xwiki.jar.
ApplicationResources_en.properties,
ApplicationResources_pl.properties,
ApplicationResources_fr.properties
etc.
So when I create ApplicationResources_cz.properties,
where can I config Xwiki to read locating words
from this file?
Thank you.
Jan
--
View this message in context: http://www.nabble.com/Czech-localization-tf3558570.html#a9936990
Sent from the XWiki- Dev mailing list archive at Nabble.com.