Re: [xwiki-devs] [VOTE] Move Attachment code from Rendering to the Model Bridge

27 Aug 2009


      Actually I don't think we can do that:

* The Rendering API must be able to work without access to the bridge/ 
model (since it can be used standalone without xwiki)
* In order to be independent of any syntax we need to have an  
Attachment class in Rendering API.
-  For example in xwiki 2.0 syntax we'd write: image:[email protected]
- In confluence syntax we'd write: !Page^img.png!
* The attachment factory that we'd have in xwiki-model(xwiki-bridge)  
would not be used to parse wiki content but for other needs. It's just  
a coincidence if we use the same syntax for these needs as the XWiki  
Syntax 2.0 syntax.

Conclusion:
* The attachment parser needs to stay in the Rendering API module
* We need "code duplication" in xwiki-model and in rendering api

Thanks
-Vincent

On Aug 26, 2009, at 5:59 PM, Vincent Massol wrote:
...
Hi,
Right now we have an AttachmentParser in the Rendering module:
@ComponentRole
public interface AttachmentParser
{
   /**
    * Extract informations from attachment location string an return  
an {@link Attachment}.
    *
    * @param attachmentLocation the location of the attachment in  
string.
    * @return the {@link Attachment} object.
    */
   Attachment parse(String attachmentLocation);
}
and
/**
* Represents an attachment in a document.
*
* @version $Id: Attachment.java 18089 2009-03-27 15:51:39Z tmortagne $
* @since 1.7.1
*/
public interface Attachment extends Cloneable
{
   /**
    * @return the name of the document containing the attachment.
    */
   String getDocumentName();
/**
    * @return the name of the attachment.
    */
   String getAttachmentName();
}
and
public class DefaultAttachement implements Attachment
...
This allows parsing attachment representations such as:
[email protected]
Since this is a generic notion I'd like to move this code to the  
xwiki-bridge module.
Note 1: This is also especially relevant since we already have an  
AttachmentName class in the bridge module.
Note 2: This will mean some changes in the Rendering API module too  
so that it doesn't depend on the bridge module but that's normal and  
technical
Thanks
-Vincent