26 Aug
2009
26 Aug
'09
5:59 p.m.
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
26 Aug
26 Aug
6:01 p.m.
And here's my +1
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
7:43 p.m.
New subject: [xwiki-devs] [VOTE] Move Attachment code from Rendering to the Model Bridge
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
+1
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
7:48 p.m.
+1
On Wed, Aug 26, 2009 at 9:29 PM, Vincent Massol <vincent(a)massol.net> 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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
7:58 p.m.
+1
On Wed, Aug 26, 2009 at 17:59, Vincent Massol<vincent(a)massol.net> 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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
8:17 p.m.
New subject: [xwiki-devs] [VOTE] Move Attachment code from Rendering to the Model Bridge
+0
Thanks,
Marius
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
27 Aug
27 Aug
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
5595
days inactive
5596
days old
6 comments
5 participants
participants (5)
-
Asiri Rathnayake -
Marius Dumitru Florea -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol