XEclipse - GSoC
XEclipse
XEclipse, which itself was initiated as a GSOC project, is a desktop tool that helps in viewing, editing and deleting XWiki pages. GSOC projects have been a major contributor in extending XEclipse. XEclipse has a basic navigator which shows the pages, objects and spaces in the Server.XEclipse Navigator
The basic features that I've decided, for now, that shall be implemented are :Drag and Drop (with editor integration too)Should check for addMergedDropListener Bug.State persistence of the Navigator and Editors.Display of attachments within the navigator- Better integration? with the workbench and editor
Standalone XWiki Rendering for a Visual Preview,switched to/from the current mozilla-browser based preview with the help of Preferences Editor?Deferred Content Manager(LazyContentProvider) with Common Navigator and XWikiXmlRPC changes for better performance/UI for a large wiki.
Deadlines
- By 5th June 2009, Go through CNF, plugin.xml, current Implementation and complete Display View IRC Chat log here - Done
After this is done, I would like to work on improving XEclipse as such, like a better Preferences Editor?, software update bundle? and more editor features? ( intergrate source editors from eclipse project, xwiki 2.0 syntax support and switch functionality )
Main Mentor: Fabio Mancinelli
Secondary Mentor: Eduard Moraru
Aug 02 2009
Lazy Retrieval of Pages in Navigator
Feature implemented.
This one was tricky!
The objective was to make the xeclipse handle a large wiki, wrt the navigator, of the range of 1000+ pages in a space. Previously, while expanding the node of space, the UI was blocked and went into an unresponsive stage, and came back/became responsive after all the tree was loaded.
Now, the current implementation does this.
The 2nd Job uses the getPages(spaceKey,start,limit) newly created xmlrpc method.
Now, the tree loading is done as a Job, and hence does not block the UI. The scrollbar is not perfect always, because the pages are added over time. Other actions, opening pages, expanding other nodes, can be done, while the lazy retrieval is taking place.
This one was tricky!
The objective was to make the xeclipse handle a large wiki, wrt the navigator, of the range of 1000+ pages in a space. Previously, while expanding the node of space, the UI was blocked and went into an unresponsive stage, and came back/became responsive after all the tree was loaded.
Now, the current implementation does this.
- Creates a Job that asynchronously gets/updates the tree every 200msec.
- Creates a Job that fetches the nodes in batches [of 20] and adds to the Tree
- Creates a pending node at the end of the tree, which is removed once when job 2 completes.
The 2nd Job uses the getPages(spaceKey,start,limit) newly created xmlrpc method.
Now, the tree loading is done as a Job, and hence does not block the UI. The scrollbar is not perfect always, because the pages are added over time. Other actions, opening pages, expanding other nodes, can be done, while the lazy retrieval is taking place.
Jun 25 2009
Drag and Drop
Drag and Drop
Updated
Possibilites:
1.
TBD: In all these cases, One DataManager to another DataManager DND should not be allowed, obviously.
Features to be created.
TBD
Anything else that you would think is necessary? :)
Updated
Possibilites:
1.
Drag and move Attachment -> Drop on some other Page (Of same space/ other space) If the space is not expanded previously, then should expand and show pages. Should Deny Drop on Space/attachment/embedded objects. Name is retained. rpc.moveAttachment is used. No need to expand pages, when hovered over with attachment. The Spaces/pages should be refreshed Accordingly, new notification instance (MOVE_ATTACHMENT)Drag and move Page -> Drop it on another Space. Name is retained. rpc.movePage is used. Deny Drop on other pages/attachments/objects. No Need to expand spaces/pages when hovered over. The spaces/pages should be refreshed accordingly, new notification instance (MOVE_PAGE). Drag under effects of Feeback_insert_after.. etc is not required.No Drag/Drop for spaces/objects. (Drop_NONE)Copy of Attachments. If Drop_copy specified, by key trigger. Almost as same as 1st point above, only use rpc.copyAttachment. If copy to same page, then newfileName should be "Copy of "+oldfileNameCopy of Page. Same as second point. rpc.copyPage used. If copy to same Space, then the newPageId should be (space).Copyof(oldpageID). There is some XMLRPC Bug with the implementation.
TBD: In all these cases, One DataManager to another DataManager DND should not be allowed, obviously.
Features to be created.
- DND of Pages between Spaces (That should automatically dnd their corresponding attachments also)
- DND of Attachment between pages.
- Automatic expansion of (+) spaces/attachment on drag action.
- Preventing illegal dnd's
- Drag and Drop Between with cnf and Editor (will have to see if possible)
TBD
- Creation of renameAttachment xmlrpc function, and a better renamePage() function. -DONE
- Creation of a generic XWikiModelObjectTransfer for handling TransferTypes. - Not Required for CNF
- Creation of DND sources and targets DONE
- Creation of feedbacks, UI features, intuitive elements. DONE
Anything else that you would think is necessary? :)
Apr 29 2009
Introduction
Hi, I am Venkatesh Nandakumar. I'll be working for the GSoC XWiki Project for Creating an better XEclipse Navigator. That, plus, I'd be extending XEclipse in General.
The general Objectives are given here XEclipse, where its linked further for more details into the specific features.
Currently, I'm looking into the existing source code of XEclipse. I also had a good look at the xmlrpc implementation.
Expect to complete this project within two months from start of 'coding begin' date: 23rd May.
The general Objectives are given here XEclipse, where its linked further for more details into the specific features.
Currently, I'm looking into the existing source code of XEclipse. I also had a good look at the xmlrpc implementation.
Expect to complete this project within two months from start of 'coding begin' date: 23rd May.