On 01/12/2011 08:30 AM, Caleb James DeLisle wrote:
>
>
> On 01/11/2011 11:50 AM, Vincent Massol wrote:
>>
>> On Jan 11, 2011, at 3:34 PM, Caleb James DeLisle wrote:
>>
>>>
>>>
>>> On 01/10/2011 12:35 PM, Vincent Massol wrote:
>>>> Hi devs,
>>>>
>>>> In lots of places we need to display the title without any markup
>>>> rendering. Examples:
>>>> - breadcrumb
>>>> - activity stream
>>>> - search results
>>>> etc
>>>>
>>>> This is such a common use case I'm proposing to add a new API for it in
>>>> Document: getPlainTitle()
>>>> It's a one liner that will do:
>>>>
>>>> getRenderedTitle("plain/1.0")
>>>
>>> You mean adding an alias to
>>> c.x.x.api.Document#getRenderedTitle("plain/1.0")?
>>
>> yes because we don't want user of the API (from velocity) hardcoding strings
>> as much as possible. They don't need to know that internally there's a plain
>> text renderer called "plain/1.0".
>>
>>> If so, I am -0 on that because as I understand, c.x.x.api.Document is on
>>> the road to being retired
>>
>>> with the old core and any new APIs there should have very compelling
>>> rationales.
>>
>> What part is not compelling?
>
> IMO The cost of increasing the amount of deprecated API outweighs the cost of
> hardcoding strings in
> script. I should have said that I think there must be some use case with a
> compelling rationale
> which is simply impossible without the addition to the API. As it is now, we
> have velocity code with
> hardcoded strings and thus it must be refactored. With this change we will
> have velocity code which
> depends on deprecated API (Correct me if c.x.x.api.Document is not
> deprecated) and thus must be
> refactored.
> I will let my -0 stand because it's not something I like the sound of but I
> accept that there are
> many valid ways of doing things and I may well be missing an important piece
> if information.
c.x.x.a.Document is deprecated implementation, but not necessarily a
deprecated API. In the future there will be a new Document API,
implemented in a different way, with a different collection of methods,
but the current and the future sets of methods will overlap. It is safe
to add new methods to API objects that are very likely to exist as
components, if the new methods are also likely to be part of the future
API. And I think that getPlainTitle should also exist in the future
Document.
>
>>
>>> At least (IMO) they
>>> should provide functionality which was previously unavailable without
>>> programming permission.
>>
>> That's why I haven't proposed to put this in XWiiDocument but only in
>> Document. Document is scripting API and it makes a lot of sense for
>> scripting, especially since we don't have a way of sharing a final static
>> String in Velocity.
>>
>> Thanks
>> -Vincent
>>
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
