Hi,
We are using mixed naming when referring to a document/page, not only on
different pages, but also in the same context (Rename step for example).
There is also an issue referring to this problem
XWIKI-5401<http://jira.xwiki.org/jira/browse/XWIKI-5401>and we need to
find an answer in order to move forward consistency.
So the question is which version we prefer: "Page" or "Document" ?
I'm voting +1 for "Page".
"Page" is more used IMO, especially in the "Space"/"Page" context.
"Page" …
[View More]is more general than "Document" and better fitted for a platform that
encapsulates all kind of content (not just documents).
Please cast your vote.
Thanks,
Caty
[View Less]
Hi devs,
Here's a proposal to move pages currently located in XE into platform modules:
* ColorThemes/*.xml --> xwiki-platform-colorthemes
* Main/Activity.xml --> xwiki-platform-activitystream-ui (move current xwiki-platform-activitytream into xwiki-platform-activitystream-api)
* Main/AllDocs.xml (and XWiki.Tableview, XWiki.Treeview, XWiki.OrphanedPages, XWiki.AllAttachments*, XWiki.DeletedDocuments, XWiki.DeletedAttachments and all pages used by those) --> new xwiki-platform-…
[View More]navigation module
* Main/RssFeeds.xml --> new xwiki-platform-help module or xwiki-platform-rss-ui module (see below)
* Main/SpaceIndex.xml --> xwiki-platform-navigation
* Main/Spaces.xml --> xwiki-platform-navigation
* Main/UserDirectory.xml --> xwiki-platform-user-ui
* Main/WebHome.xml --> xwiki-platform-dashboard-ui
* Main/WebRss.xml --> new xwiki-platform-rss-ui module, we would create a xwiki-platform-rss-api module too where we will move the feed plugin
* Main/Welcome.xml --> move to xwiki-platform-dashboard-ui since it's a dashboard gadget which we could consider as a default widget
* Sandbox/*.xml --> xwiki-platform-sandbox module (or xwiki-platform-help module)
* XWiki/XWikSyntax.xml --> xwiki-platform-help module
* XWiki/AttachmentSelector.xml --> xwiki-platform-user-ui or new xwiki-platform-attachmentselector module
* XWiki/ClassSheet, ClassTemplate, ObjectSheet, XWikiClasses,
* XWiki/GadgetClass.xml --> xwiki-platform-dashboard-ui
* XWiki/LiveTableResult*.xml --> new xwiki-platform-livetable module
* XWiki/MessageStreamConfig.xml --> new xwiki-platform-messagestream-ui module (and move xwiki-platform-message in xwiki-platform-message-api module)
* XWiki/RequestsStatus.xml --> xwiki-platform-administration module or remove from platform till we integrate it in the Admin as an admin tool somewhere since right now I think it's available in the Admin tools application
* XWiki/RequiredRightClass.xml --> since it's used in lots of other ui modules I'd propose to move it in java code as a class created on startup. Alternatively start creating a xwiki-platform-rights-ui module (or xwiki-platform-permission-ui module) and move it there
* XWiki/SharePage.xml --> not sure…. maybe in a xwiki-platform-share or xwiki-platform-sharepage module
* XWiki/TemplateProvider*.xml --> xwiki-platform-administration for the moment
* XWiki/WebHome.xml --> xwiki-platform-administration module
* XWiki/WebPreferences.xml --> xwiki-platform-administration module
WDYT?
Please try to tell me if you're ok for each line if you have time ;)
Thanks
-Vincent
[View Less]
Hi,
Im trying to fix http://jira.xwiki.org/jira/browse/XWIKI-4274
Basically if you do $xwiki.getDocument("someDoc").getRenderedContent()
it'll get executed in the context of the current doc which I believe
is wrong especially since other signatures of getRenderedContent()
execute in the target document's context.
I have fixed this locally but found that admin.vm for example is
assuming that getRenderedContent() will get executed in the context of
the calling doc (i.e. XWiki.Import …
[View More]when doing an import for example).
FYI the chain flow is admin.vm -- getRenderedContent() -->
XWiki.AdminSheet --> XWiki.AdminImportSheet --> importinline.vm, which
requires the current doc to be XWiki.Import (to get/put attachments
from/to it).
I can fix this easily using a new getRenderedContent signature I've
introduced.
However I'm wondering if we have other places that incorrectly use
getRenderedContent() and assume it won't be rendered in the context of
the target document.
Is this change too dangerous to make? If not know, we'll need to it
quickly (2.1M1?) since it's an important bug IMO.
WDYT?
Thanks
-Vincent
[View Less]
Hi devs,
Running mvn dependency:dependency-analyze produces interesting results.
For example:
[INFO] ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
[INFO] Building XWiki Commons - Properties 3.2-SNAPSHOT
[INFO] -----------------------------------------------------------------------------------------------------------------------------------------------------------------…
[View More]----------
…
[INFO] --- maven-dependency-plugin:2.3:analyze (default-cli) @ xwiki-commons-properties ---
[WARNING] Used undeclared dependencies found:
[WARNING] org.slf4j:slf4j-api:jar:1.6.1:compile
[WARNING] javax.inject:javax.inject:jar:1:compile
[WARNING] Unused declared dependencies found:
[WARNING] org.xwiki.commons:xwiki-commons-component-api:jar:3.2-SNAPSHOT:compile
[WARNING] org.xwiki.commons:xwiki-commons-test:jar:3.2-SNAPSHOT:test
[WARNING] org.hibernate:hibernate-validator:jar:4.2.0.Final:test
[WARNING] org.hamcrest:hamcrest-core:jar:1.1:test
[WARNING] org.jmock:jmock:jar:2.5.1:test
The question is (for this module but more generally for all others):
* Should we add slf4j and javax.inject reps in the pom.xml for this module? (for ex today slf4j and javax.inject are found in the component-api dep)
I think we should, wdyt?
Note that the "Unused declared dependencies found:" doesn't always generate correct results as is the case here. This is mostly because it's a static byte code check so any dep used at runtime will be considered unused.
See http://www.sonatype.com/books/mvnex-book/reference/optimizing-sect-dependen…
Thanks
-Vincent
[View Less]
Hi,
*Short version* for voting:
*A*. Creation of a new wiki on xwiki.org farm that will hold development
process details about a specific feature. This wiki will deprecate
dev.xwiki.org:Design and incubator.myxwiki.org
*B*. Vote on naming alternatives for this new wiki:
design.xwiki.orgincubator.xwiki.org
*C*. UI on how a Proposal will be displayed in this new wiki (example
AppWithinMinutes):
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/XWikiOrgDesignWiki
---------------------…
[View More]---------------------------
*Long version: *
Right now development process activities are located in multiple places:
- Analysis + Architecture: http://dev.xwiki.org/xwiki/bin/view/Design/
- Analysis + User Interface:
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/
- Other: http://xwiki.markmail.org/, http://jira.xwiki.org, chats, git
comments, etc.
This process can be hard to optimize and information is hard to track if
you are looking for specific information.
And the worst part of it is that is hard to automatize and lots of the
items need manual gathering or search.
*Part A. *
This mail is about combining http://dev.xwiki.org/xwiki/bin/view/Design/andhttp://incubator.myxwiki.org/ work in a single place.
This has already been discussed several times before (
http://xwiki.markmail.org/thread/kc32dufsf7nyyt6s and
http://xwiki.markmail.org/thread/izj6aiyodwqia4vl) and the vote was
favorable in this direction.
The proposal was to create a new wiki called design.xwiki.org that will
contain the combined information and that will target developers.
The new wiki will be used to gather only proposal's development process
information: requirements, architecture, solutions alternatives, user
interface variants, planning, etc. for a specific feature/idea/improvement.
After the proposal is implemented it will be properly documented in the
right location for users (ex platform.xwiki.org).
It is acceptable to have CSS + JS code on this wiki in order to demonstrate
the functionality of the proposals, but we should not add
experimental/dangerous code (groovy scripts, jars, etc.). For this case it
is advisable to use a test machine, share your own instance or use the
contrib.xwiki.org repository for hosting.
The version upgrades will be handle by a community admin and the wiki
gardening by me.
The data from incubator.myxwiki.org and dev.xwiki.org:Design will be moved
gradually after the new wiki is created.
*Part B. *
You should state your opinion regarding which name is better for the new
wiki:
- design.xwiki.org
- incubator.xwiki.org
- we accept other proposals.
*Part C.*
I've made a proposal on how a proposal page would look like:
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/XWikiOrgDesignWiki
The proposal page will gather all the information related to it, making it
easier to track it's progress.
The entries will be separated depending on 4 categories: Analysis,
Architecture, User Interface and Implementation, each category having it's
own status, participants, jiras and timeframe.
Categories are not mandatory for all proposals, smaller proposals will have
just the related pages for certain areas.
Each proposal will store it's data in a dedicated space.
The implementation of the proposal will be handled by me.
Let me know what you think.
Thanks,
Caty
[View Less]
Hi devs,
I think it would be great to have some indication of how many active instances of XWiki are out there in the wild. The idea is not so much to know the figure but to see how this figures evolves and thus to see if we're doing things right. It will also give us information about how quickly or slowly our user base upgrades from version to version.
Here's my proposal:
* When installing XWiki on a clean DB (ie first time install) generate a unique id and store it in the DB (similar to …
[View More]the version we're storing in the DB but using some UUID). Thus when an install is upgraded the same id is preserved.
* When the Extension Manager is used and thus connects to extensions.xwiki.org (default extension repository), this unique ID is sent too.
* In addition the version of XE is sent too
* On extensions.xwiki.org side, we only log the unique ID/XE version **without** logging the IP or any other information thus ensuring that the ID remains completely anonymous
* We display a counter on xwiki.org about the # of active instances of XE with a graph about XE versions used
WDYT?
Thanks
-Vincent
[View Less]
Could be useful:
http://ocpsoft.com/prettytime/
Idea of usage: For ex we could use that to show the last modified
document dates for dates in the past week (for ex):
"Document created 2 days ago"
It's in the maven central repo and it's under LGPL
-Vincent
Hi devs,
Sergiu has started a script to fully automate a release (more to come - Sergiu will document what it does soon). The only part not automated are the Release Notes.
IMO we can "automate" it by a process which I propose to be:
* An issue can only be closed if it's documented on xwiki.org and on the release notes page for the upcoming release.
* We collectively enforce this by reopening issues if someone doesn't do the first point, asking him/her to do it
This will have some nice …
[View More]effects:
* xwiki.org will be more up to date than it is now
* it's up to the developer to document what they do (I don't think it's good to push this to someone else) which is good since they have the most knowledge (side note: it doesn't mean we don't need a technical writer to improve on the documentation done by developers but it would be about style and not about content)
* the release notes will be ready for the release, as we progress and the burden of writing the release notes will not fall on the shoulders of the Release Manager (there's no reason it should)
* the whole release process will almost be a joy to do
* with a fully automated release process it means we'll be able to perform a lot more bugfix releases which is good for our users
Here's my +1
Thanks
-Vincent
[View Less]
Hi devs,
For the upcoming Application Within Minutes I need to enhance the
XWiki platform with the ability to generate the page name
automatically when creating a new wiki page. For some applications it
doesn't make sense to have two creation steps: (1) specify the wiki
page name (i.e. the location) and then (2) edit the new wiki page with
the specified name. Let me give you two examples:
* It would be cool to be able to create a new blog post in a single
step. The blog post name could be …
[View More]generated from the blog post title
specified in the edit form.
* An application that manages holiday requests doesn't need meaningful
page names (i.e. free text, like a blog post would have) but something
like Request_XYZ, where XYZ is a unique counter/identifier.
These applications should be able to create new wiki pages with
automatically generated names without writing their custom create
forms.
Since 3.2RC1 was planed for today and these changes are in the 3.2
roadmap, here's a proposal that I think I can implement quickly and
safely:
(1) Introduce two new components:
// Used to generate a document name that doesn't have to be unique
(e.g. by cleaning the document title).
DocumentReferenceGenerator#generate(DocumentModelBridge):DocumentReference
// Used to make a document name unique (by suffixing an unique
counter/identifier)
DocumentReferenceDifferentiator#differentiate(DocumentReference):DocumentReference
(2) Modify editinline.vm to store "documentReferenceGenerator" and
"documentReferenceDifferentiator" request parameters in two hidden
input fields so that they are passed to the save action. Obviously,
these are component hints.
(3) Modify editactions.vm to replace "Save & View" + "Save & Continue"
with "Create" when "documentReferenceGenerator" or
"documentReferenceDifferentiator" (or both) request parameters are
set.
(4) Modify SaveAction to take into account these two request
parameters (only if they are specified). Something along these lines:
generateDocumentReference(doc)
synchronize(lock) {
doc.copyDocument(differentiate(generatedDocumentReference)).save();
}
I'm not sure where to place the two components from (1) though. WDYT?
Thanks,
Marius
[View Less]