[xwiki-devs] [Rendering] WikiModel API change for merging getAttachmentURL and getImageURL?
19 Oct
2010
19 Oct
'10
8:43 p.m.
Hi,
We currently have 2 methods introduced in 2.5 timeframe in the WikiModel class:
String getAttachmentURL(ResourceReference attachmentReference);
String getImageURL(ResourceReference attachmentReference, Map<String, String>
parameters);
I think we should merge them into a single method in charge of returning the URL of any
resource reference:
getResourceURL(ResourceReference reference, Map<String, String> parameters);
Note that this would assume that all references have a URL associated to them. It's
not always true (it's true for documents, attachments, url, interwiki and the future
icon/symbol but false for path and mailto). We could return null for resource types that
have no associated URLs.
The reason I'm proposing this because in order to implement support for symbol/icon
I'd need to add a new method to WikiModel: getIconURL(ResourceReference iconReference)
but I feel it's better to have a single getResourceURL().
WDYT?
Thanks
-Vincent
19 Oct
19 Oct
10:04 p.m.
On 10/19/2010 09:43 PM, Vincent Massol wrote:
Hi,
We currently have 2 methods introduced in 2.5 timeframe in the WikiModel class:
String getAttachmentURL(ResourceReference attachmentReference);
String getImageURL(ResourceReference attachmentReference, Map<String, String>
parameters);
I think we should merge them into a single method in charge of returning the URL of any
resource reference:
getResourceURL(ResourceReference reference,
Map<String, String> parameters);
Are you going to use the current implementation of getImageURL for all
ResourceType.ATTACHMENT resources?
Thanks,
Marius
Note that this would assume that all references have a URL associated to them. It's
not always true (it's true for documents, attachments, url, interwiki and the future
icon/symbol but false for path and mailto). We could return null for resource types that
have no associated URLs.
The reason I'm proposing this because in order to implement support for symbol/icon
I'd need to add a new method to WikiModel: getIconURL(ResourceReference iconReference)
but I feel it's better to have a single getResourceURL().
WDYT?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
20 Oct
20 Oct
10:57 a.m.
On Oct 19, 2010, at 10:04 PM, Marius Dumitru Florea wrote:
On 10/19/2010 09:43 PM, Vincent Massol wrote:
You're right, since we have no way of differentiating links and images in
ResourceReference we need to have 2 methods:
- getImageURL
- getLinkURL
(better than getAttachmentURL IMO)
Thanks
-Vincent
Hi,
We currently have 2 methods introduced in 2.5 timeframe in the WikiModel class:
String getAttachmentURL(ResourceReference attachmentReference);
String getImageURL(ResourceReference attachmentReference, Map<String, String>
parameters);
I think we should merge them into a single method in charge of returning the URL of any
resource reference:
getResourceURL(ResourceReference reference,
Map<String, String> parameters);
Are you going to use the current implementation of getImageURL for all
ResourceType.ATTACHMENT resources?
Thanks,
Marius
>
> Note that this would assume that all references have a URL associated to them.
It's not always true (it's true for documents, attachments, url, interwiki and the
future icon/symbol but false for path and mailto). We could return null for resource types
that have no associated URLs.
>
> The reason I'm proposing this because in order to implement support for
symbol/icon I'd need to add a new method to WikiModel: getIconURL(ResourceReference
iconReference) but I feel it's better to have a single getResourceURL().
>
> WDYT?
>
> Thanks
> -Vincent
11:26 a.m.
New subject: [xwiki-devs] [Rendering] WikiModel API change for merging getAttachmentURL and getImageURL?
On Wed, Oct 20, 2010 at 10:57, Vincent Massol <vincent(a)massol.net> wrote:
On Oct 19, 2010, at 10:04 PM, Marius Dumitru Florea wrote:
+1, it follows events names
On 10/19/2010 09:43 PM, Vincent Massol wrote:
You're right, since we have no way of differentiating links and images in
ResourceReference we need to have 2 methods:
- getImageURL
- getLinkURL
(better than getAttachmentURL IMO) Hi,
We currently have 2 methods introduced in 2.5 timeframe in the WikiModel class:
String getAttachmentURL(ResourceReference attachmentReference);
String getImageURL(ResourceReference attachmentReference, Map<String, String>
parameters);
I think we should merge them into a single method in charge of returning the URL of any
resource reference:
getResourceURL(ResourceReference reference,
Map<String, String> parameters);
Are you going to use the current implementation of getImageURL for all
ResourceType.ATTACHMENT resources?
Thanks
-Vincent
--
Thomas Mortagne
Thanks,
Marius
>
> Note that this would assume that all references have a URL associated to them.
It's not always true (it's true for documents, attachments, url, interwiki and the
future icon/symbol but false for path and mailto). We could return null for resource types
that have no associated URLs.
>
> The reason I'm proposing this because in order to implement support for
symbol/icon I'd need to add a new method to WikiModel: getIconURL(ResourceReference
iconReference) but I feel it's better to have a single getResourceURL().
>
> WDYT?
>
> Thanks
> -Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
11:41 a.m.
New subject: [xwiki-devs] [Rendering] WikiModel API change for merging getAttachmentURL and getImageURL?
On 10/20/2010 12:26 PM, Thomas Mortagne wrote:
On Wed, Oct 20, 2010 at 10:57, Vincent
Massol<vincent(a)massol.net> wrote:
+1
Thanks,
Marius
On Oct 19, 2010, at 10:04 PM, Marius Dumitru Florea wrote:
+1, it follows events names On 10/19/2010 09:43 PM, Vincent Massol wrote:
You're right, since we have no way of differentiating links and images in
ResourceReference we need to have 2 methods:
- getImageURL
- getLinkURL
(better than getAttachmentURL IMO) Hi,
We currently have 2 methods introduced in 2.5 timeframe in the WikiModel class:
String getAttachmentURL(ResourceReference attachmentReference);
String getImageURL(ResourceReference attachmentReference, Map<String, String>
parameters);
I think we should merge them into a single method in charge of returning the URL of any
resource reference:
getResourceURL(ResourceReference reference,
Map<String, String> parameters);
Are you going to use the current implementation of getImageURL for all
ResourceType.ATTACHMENT resources?
Thanks
-Vincent
Thanks,
Marius
>
> Note that this would assume that all references have a URL associated to them.
It's not always true (it's true for documents, attachments, url, interwiki and the
future icon/symbol but false for path and mailto). We could return null for resource types
that have no associated URLs.
>
> The reason I'm proposing this because in order to implement support for
symbol/icon I'd need to add a new method to WikiModel: getIconURL(ResourceReference
iconReference) but I feel it's better to have a single getResourceURL().
>
> WDYT?
>
> Thanks
> -Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
21 Oct
21 Oct
1:17 a.m.
On 10/20/2010 10:57 AM, Vincent Massol wrote:
On Oct 19, 2010, at 10:04 PM, Marius Dumitru Florea wrote:
I don't like getLinkURL. Link is almost a synonym of URL, so it sounds
like a pleonasm a bit, at least for me.
getResourceURL?
On 10/19/2010 09:43 PM, Vincent Massol wrote:
You're right, since we have no way of differentiating links and images in
ResourceReference we need to have 2 methods:
- getImageURL
- getLinkURL
(better than getAttachmentURL IMO) Hi,
We currently have 2 methods introduced in 2.5 timeframe in the WikiModel class:
String getAttachmentURL(ResourceReference attachmentReference);
String getImageURL(ResourceReference attachmentReference, Map<String, String>
parameters);
I think we should merge them into a single method in charge of returning the URL of any
resource reference:
getResourceURL(ResourceReference reference,
Map<String, String> parameters);
Are you going to use the current implementation of getImageURL for all
ResourceType.ATTACHMENT resources? Thanks
-Vincent
>
> Thanks,
> Marius
>
>>
>> Note that this would assume that all references have a URL associated to them.
It's not always true (it's true for documents, attachments, url, interwiki and the
future icon/symbol but false for path and mailto). We could return null for resource types
that have no associated URLs.
>>
>> The reason I'm proposing this because in order to implement support for
symbol/icon I'd need to add a new method to WikiModel: getIconURL(ResourceReference
iconReference) but I feel it's better to have a single getResourceURL().
>>
>> WDYT?
>>
>> Thanks
>> -Vincent
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
7:22 a.m.
On Oct 21, 2010, at 1:17 AM, Sergiu Dumitriu wrote:
On 10/20/2010 10:57 AM, Vincent Massol wrote:
If you check the previous mails in this thread you'll see that this was my original
proposal but it doesn't work since you cannot know whether a resource reference is for
an image or for a link. Both Marius, Thomasn and I noticed it. As Thomas said the proposal
is in line with the rest of the rendering module (different events for links and images,
different renderers, etc).
Thanks
-Vincent
On Oct 19, 2010, at 10:04 PM, Marius Dumitru Florea wrote:
I don't like getLinkURL. Link is almost a synonym of URL, so it sounds
like a pleonasm a bit, at least for me.
getResourceURL? On 10/19/2010 09:43 PM, Vincent Massol wrote:
You're right, since we have no way of differentiating links and images in
ResourceReference we need to have 2 methods:
- getImageURL
- getLinkURL
(better than getAttachmentURL IMO) Hi,
We currently have 2 methods introduced in 2.5 timeframe in the WikiModel class:
String getAttachmentURL(ResourceReference attachmentReference);
String getImageURL(ResourceReference attachmentReference, Map<String, String>
parameters);
I think we should merge them into a single method in charge of returning the URL of any
resource reference:
getResourceURL(ResourceReference reference,
Map<String, String> parameters);
Are you going to use the current implementation of getImageURL for all
ResourceType.ATTACHMENT resources? > Thanks
> -Vincent
>>
>> Thanks,
>> Marius
>>
>>>
>>> Note that this would assume that all references have a URL associated to
them. It's not always true (it's true for documents, attachments, url, interwiki
and the future icon/symbol but false for path and mailto). We could return null for
resource types that have no associated URLs.
>>>
>>> The reason I'm proposing this because in order to implement support for
symbol/icon I'd need to add a new method to WikiModel: getIconURL(ResourceReference
iconReference) but I feel it's better to have a single getResourceURL().
>>>
>>> WDYT?
>>>
>>> Thanks
>>> -Vincent
10:10 a.m.
New subject: [xwiki-devs] [Rendering] WikiModel API change for merging getAttachmentURL and getImageURL?
On Thu, Oct 21, 2010 at 01:17, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote:
On 10/20/2010 10:57 AM, Vincent Massol wrote:
As i said it follow the name of the rendering event for which it's
used (begin/endLink and onImage).
Also an image is a resource too, the point is to make a difference
between an URL used in a link and an URL used in an image. An image is
a resource too so the difference would not really make sense.
On Oct 19, 2010, at 10:04 PM, Marius Dumitru Florea wrote:
I don't like getLinkURL. Link is almost a synonym of URL, so it sounds
like a pleonasm a bit, at least for me. On 10/19/2010 09:43 PM, Vincent Massol wrote:
You're right, since we have no way of differentiating links and images in
ResourceReference we need to have 2 methods:
- getImageURL
- getLinkURL
(better than getAttachmentURL IMO) Hi,
We currently have 2 methods introduced in 2.5 timeframe in the WikiModel class:
String getAttachmentURL(ResourceReference attachmentReference);
String getImageURL(ResourceReference attachmentReference, Map<String, String>
parameters);
I think we should merge them into a single method in charge of returning the URL of any
resource reference:
getResourceURL(ResourceReference reference,
Map<String, String> parameters);
Are you going to use the current implementation of getImageURL for all
ResourceType.ATTACHMENT resources?
getResourceURL?
--
Thomas Mortagne
Thanks
-Vincent
>
> Thanks,
> Marius
>
>>
>> Note that this would assume that all references have a URL associated to them.
It's not always true (it's true for documents, attachments, url, interwiki and the
future icon/symbol but false for path and mailto). We could return null for resource types
that have no associated URLs.
>>
>> The reason I'm proposing this because in order to implement support for
symbol/icon I'd need to add a new method to WikiModel: getIconURL(ResourceReference
iconReference) but I feel it's better to have a single getResourceURL().
>>
>> WDYT?
>>
>> Thanks
>> -Vincent
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
20 Oct
20 Oct
10:19 a.m.
New subject: [xwiki-devs] [Rendering] WikiModel API change for merging getAttachmentURL and getImageURL?
On Tue, Oct 19, 2010 at 20:43, Vincent Massol <vincent(a)massol.net> wrote:
Hi,
We currently have 2 methods introduced in 2.5 timeframe in the WikiModel class:
String getAttachmentURL(ResourceReference attachmentReference);
String getImageURL(ResourceReference attachmentReference, Map<String, String>
parameters);
I think we should merge them into a single method in charge of returning the URL of any
resource reference:
How do you make the difference between a link to an attachment and an
image src then ?
getResourceURL(ResourceReference reference, Map<String, String> parameters);
Note that this would assume that all references have a URL associated to them. It's
not always true (it's true for documents, attachments, url, interwiki and the future
icon/symbol but false for path and mailto). We could return null for resource types that
have no associated URLs.
The reason I'm proposing this because in order to implement support for symbol/icon
I'd need to add a new method to WikiModel: getIconURL(ResourceReference iconReference)
but I feel it's better to have a single getResourceURL().
WDYT?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
5132
days inactive
5134
days old
8 comments
4 participants
participants (4)
-
Marius Dumitru Florea -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol