[
http://jira.xwiki.org/jira/browse/XECLIPSE-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_19145
]
Fabio Mancinelli commented on XECLIPSE-30:
------------------------------------------
Modified the way images are handled and leveraged the method
getImageDescriptor() in XWikiEclipsePlugin for getting image descriptors for
icons.
Done in Revision: 5364
* Moved icons to standard /icons location
* Removed method loadIconImage(String) from GUIUtils
* Used standard plugin methods for getting ImageDescriptors for icons
* Renamed Activator to XWikiEclipsePlugin
* Fixed name mismatch in the PLUGIN_ID in XWikiEclipsePlugin and the one
declared in plugin.xml
> Design improvements and refactoring
> -----------------------------------
>
> Key: XECLIPSE-30
> URL: http://jira.xwiki.org/jira/browse/XECLIPSE-30
> Project: XWiki Eclipse Integration
> Issue Type: Task
> Components: Build, Test and Packaging
> Affects Versions: 1.0 M2, 1.0
> Reporter: Fabio Mancinelli
> Assigned To: Fabio Mancinelli
>
> Refactor XEclipse in order to leverage Eclipse platform's features that
> (...that to some extent, have been re-implemented in XEclipse)
> 1) Deferred tree content managers.
> Basically a deferred tree content manager allows you to "fetch" tree children
> in a deferred way.
> One example is the "SVN Repository" or "CVS Repository" views in your Eclipse
> IDE. When you expand a node it displays a "Pending..." element
> and, when the fetching job is over, the actual elements (i.e., files and
> directories available on the repository) are displayed.
> The same mechanism could be used in XEclipse to fetch Spaces and Pages.
> Using the deferred tree content fetching mechanism eliminates the need of
> having additional logic in XWikiSpace for understanding when pages are ready
> (i.e., all the code that manages isPagesReady in XWikiSpace.java). You will
> simply have a method getPages that could take possibly forever and that
> directly fetches the pages from the XMLRPC source (or from the offline cache).
> I think that this will also have impact on the Decorators that are used to
> wrap XWiki* elements in order to provide a visual feedback on what's going on
> (i.e., all the GuiUtils.runOperationWithProgress will be unnecessary since
> the deferred tree content manager will take care of everything)
> 2) Adapters
> There is a TreeAdapter interface that is used for providing labels, children
> and so on.
> All classes that can be "displayed" in a tree implements this interface
> (i.e., XWikiConnection, XWikiPage, XWikiSpace).
> I this "pollutes" the model because, for example, getPages and
> getTreeChildren basically return the same thing and, therefore, are
> duplicated methods. Moreover in this way we put "GUI"-oriented stuff in the
> model and this is not good.
> The Eclipse platform has a mechanism for providing adapters that are able to
> give information about model elements to GUI components[2].
> When you need structural information about an object, you can then query the
> platform for an adapter that matches a given interface and is suitable for a
> given object. In our case I can register an adapter for XWikiSpace that
> implements the getChildren method and that will simply call the getPages
> method of the XWikiSpace model object.
> In this way we can clearly separate the "GUI" code from the "model" code and
> leave Eclipse handle the rest.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.xwiki.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
notifications mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/notifications
