Hi.
I just committed JCRStore prototype based on JCRv1 to sandbox/jcrstore
Ideas of the prototype:
1. use value objects for storage (xwiki data model proposal:
sandbox/org.xwiki.model)
org.xwiki.store.value.*
value objects allow us to eliminate xwiki-core dependency in
jcrstore.
we can reuse value objects in new data model later as in
sandbox/org.xwiki.model.
2. put all storage specific code in DAO classes.
Stores will remain only business code and delegate storage stuff to DAOs.
(stores will deprecated by new data model later)
3. convert value objects to/from xwiki business objects.
org.xwiki.store.value.ValueConverter
planed jcr hierarchy:
(node name (node type))
/
<space> (xwiki:space)
<docname> (xwiki:document)
objects
<class.name>
<number> (xwiki:object)
properties (Jcr Value or Value[])
attachments
<filename> (xwiki:attachment extends nt:resource)
lock (xwiki:lock)
translations
<language> (xwiki:document) (translations of document)
the main problem:
JCRStore needs JCRSQL2 language from JCRv2 (JCRv1 has very limited query
languages), but:
JSR-283 aka JCR v2 isn't still out. It was planed for September.
http://jcp.org/en/jsr/detail?id=283
Jackrabbit's JCRSQL2 parser is still in progress (and unusable yet).
eXoJCR v2 also in progress: http://jira.exoplatform.org/browse/JCRS
I'm afraid JCR v2 may not release before XE-1.7. JCRv2 release was
shifted several times before. :(.
JcrStore plans:
implement base JcrDAOs. (JcrDocumentDAO is ready)
try to run xwiki on jcrstore. (not fully possible without JCRSQL2, but
may show some problems in store)
implement XWQL to JCRSQL2 translator.
wait for JCRv2 or at least working JCRSQL2.
test XWQL on JCRSQL2.
rewrite all HQL queries to XWQL.
Delivery date:
If JCRv2 (or JCRSQL2) will release in a ~week then I'll implement base
functionality in 1.7M2 and improve it in 1.7RC1.
If not then 1.8M1
PS: I'm sorry for long delay. I was ill 2.5 last weeks. It very reduce
my activity.
--
Artem Melentyev
Hi All,
Thanks for your support to make FoXWiki a public plugin :)
Btw, if you have any suggestions for new features you expect in a future
version of FoXWiki, please dump them in this thread ;)
- Asiri
On Sat, Oct 25, 2008 at 7:42 AM, Mozilla Add-ons <nobody(a)mozilla.org> wrote:
> Congratulations! Your nominated add-on, FoXWiki, has been reviewed by a
> Mozilla Add-ons editor who approved your add-on to be public.
>
> Your most recent version (1.0b) has also been made public.
>
> You can view your public add-on now at:
> http://addons.mozilla.org/addon/2358
>
> Review Information:
> Reviewer: shane hansen
> Comments: Congratulations, your addon has been approved for public
> status.<br />
> <br />
> Keep up the good work!<br />
> I did notice that you had an empty "general" preferences tab, which is kind
> of distracting for users.
> If you have questions about this review, please e-mail
> amo-editors(a)mozilla.org or join #addons on irc.mozilla.org.
>
> Mozilla Add-ons
> http://addons.mozilla.org
>
>
Hello XWikiers,
I'm importing the base xar on a brand new xwiki and... well...
- upload works flawlessly
- clicking on the archive as well (this should have a wait UI btw!)
- but then I get the following text with no information in the console
>
> Import
>
> Import
> Importing curriki-wiki.xar: Error while preparing importing
>
> * 0 Document(s) installed
> * 0 Document(s) skipped
> * 0 Document(s) with error
>
(preceded by the warning the wiki is empty)
Is there a switch somewhere to raise verbosity and get info about what
went wrong?
As I said, the list of files is there (and big).
paul
PS: for curriki-aware folks, that xar was created with the current
curriki checkout after removal of package.xml. I get the same results
if I use the svn-ed package.xml.
Hi All,
We need your support to make FoXWiki a public extension at
addons.mozilla.org. The new version of FoXWiki includes all the features of
previous version plus support for webdav. All you need to do is to try out
new FoXWiki and rate / review the extension.
Steps :
1. You need to have an account at addons.mozilla.org (this is the ugly part)
2. login to addons.mozilla.org and install
https://addons.mozilla.org/en-US/firefox/addon/2358
3. Test FoXWiki using our test server located @
http://91.121.237.216/xwiki/bin/view/Main/ (Refer to screenshots provided at
the plugin's location)
4. Rate / Review the extension :)
Please keep in mind that webdav support is not yet included in official XE
releases.
Let us know if you have any trouble.
Thanks.
- Asiri
ps : Introduction to FoXWiki (old) :
http://soal.xwiki.com/xwiki/bin/view/Code/FoXWiki
This should interest Asiri:
http://www.theserverside.com/news/thread.tss?thread_id=50906
"
Milton is an open source java library for implementing desktop
integration in your web apps with WEBDAV.
For those not familiar with WEBDAV, its like FTP but implemented in
HTTP. Its a mature standard and supported natively in all operating
systems.
Once integrated, your users can view and/or manipulate remote data in
your application using drag and drop of files and folders in their
native OS file browser - eg Windows Explorer, Nautilus, etc, over HTTP.
Milton is agnostic of the nature of your data and can be used with any
type of persistence mechanism, including hibernate, JPA, etc.
Milton can be integrated easily into most web apps by implementing a
Resource interface and a ResourceFactory, and adding the Milton
servlet to web.xml.
Milton allows you to specify which http methods to support (eg DELETE,
PUT, MKCOL, etc). HTTP authentication and authorisation are delegated
to your application logic.
Milton is not bound to the Servlet API, so it can easily be integrated
into alternative web servers.
"
Note: I'm not saying we should move to that. Just that we need to keep
it in our radar and decide at some point if it's better or not better
than the jackrabbit api we're using.
Thanks
-Vincent
Jean-Vincent Drean wrote:
> Side developer note : I'd be in favor of removing the link on the
> group name (see ** above), I think the RMUI should be self-sufficient,
> the AJAX UI in the inline view of group pages is disturbing imho. WDYT
> ?
The question is how much do we target advanced developers versus normal
users/administrators. The link is there so that somebody that knows
XWiki well can go to the document and edit the objects, or manipulate in
other ways the document holding the group.
I guess that if there's an interface powerful and stable enough to
render raw object editing useless, we could completely hide this kind of
documents, not just from the RMUI, but from all other applications.
After all, an advanced dev can always manually enter the right URL
manually and go on from there.
WDYT?
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
The XWiki development team is pleased to announce the release of XWiki
Enterprise Manager 1.4.
Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download
This release is based on XWiki Enterprise 1.6.1.
Changes from 1.3:
* As usual the main news is on XE side (from 1.5.1 to 1.6.1)
* Some UI improvements on information panels
For more information see the Release notes at:
http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXEM14
Thanks
-The XWiki dev team
The XWiki development team is pleased to announce the release of XWiki
Enterprise 1.7 Milestone 1.
Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download
First milestone of the XWiki Enterprise 1.7 version.
Main changes:
* Work in progress on the new XWiki Syntax v2.0
* XWiki Syntax 2.0 allow wiki syntax inside links
* Work in progress on the new experimental WYSIWYG editor.
Important bug fixes:
* Saving a blank wiki page throws exception in Oracle
* Registration is still possible when right to register for
Unregistered user is explicit set to deny
* Documents with name with spaces or other special chars can't
properly save added image in WYSIWYG editor
* Support of dots in ldap login has introduce a security hole
Note that general goals for XWiki Enterprise 1.7 are:
* Working and usable (i.e. users can use them for their day to day
work instead of the old Syntax and old WYSIWYG editor) versions of new
rendering and new WYSIWYG editor.
* Working JCR (can be used for day to day work instead of Hibernate).
* French XE
* Blog revamping
* Webdav integration
For more information see the Release notes at:
http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise17M1
Thanks,
The XWiki dev team
Hi Marius and everyone,
Here's an idea of a specification for macro handling in the new
wysiwyg editor:
* Macros are rendered when displayed in the editor
* There's an outline so that the user can see what content corresponds
to a macro
* When the cursor is inside a macro the background color is changed
* Clicking on Edit Macro to edit the selected macro
* There's a background thread running that re-renders the page (and
thus the macro) every N seconds. We need this since the macro content
depends on other content (for example the TOC macro will depend on
sections, the velocity macro will depend on values set in other
velocity macros, etc). We should also have a way to let the user
refresh the rendering manually.
** Note that since there are both inline and block macros we also need
to refresh the rendering for that reason. For ex, if you put a
velocity macro inside a list item and then you remove the list item
the renderer result of the macro will be different (in the second case
an extra paragraph will be added).
* We should also have a button to switch between rendering macros and
not rendering macros. For example when a page is including another
page with some large content the user might want to disable macro
rendering to focus only on the content of the current page. The
default should be to render macros.
WDYT?
Thanks
-Vincent