27 Aug
2009
27 Aug
'09
3:07 p.m.
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:Space.Page@img.png
- 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:
Space.Page(a)some.attachment
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